docs: say that merging to main is a rollout, because it is - #5
Merged
Conversation
Both documents claimed a staging step that no longer exists. The README said the tag is "advanced only after a change has run green on a real repo" and told the reader to verify on a repo pinned to main "then let the tag move". AGENTS.md said a change here "is inert until v1 moves" and that merging to main "no longer changes anyone's CI". None of that has been true since the release automation landed. The successCmd force-moves the major tag in the same run as the release, so merging to main puts every caller on the new code immediately, including the picker and composite actions these workflows reference at v1 internally. The bullet promising the opposite sat directly above the paragraph describing the automation that broke it. The automatic move is deliberate and stays. What changes is that the documents now describe it: verify in the pull request, because after the merge it is already live, and rolling back is a tag move rather than a revert. Also answers the question the setup invites. The successCmd derives the major from the version, so it needs no change at v2 or beyond: 2.0.0 creates v2 and leaves v1 frozen at the last 1.x, which is what a caller pinning a major is paying for. Verified against the real template for 1.0.1, 1.4.0, 2.0.0, 3.1.2 and 10.0.0, the last of which would break a naive first-character approach. The caveat that comes with it is recorded too: main is the only release branch, so once 2.0.0 ships there is no way to release a 1.x patch without adding a maintenance branch, and that is easier to add before it is needed.
|
🎉 This PR is included in version 1.0.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both documents claimed a staging step that no longer exists.
main, verify on one repo pinned tomain, then let the tag move"v1moves. Merging tomainno longer changes anyone's CI."mainchanges everyone's CI immediatelyThe
successCmdforce-moves the major tag in the same run as the release, so merging puts every caller on the new code before anyone looks at it. That includes the picker and composite actions these workflows reference at@v1internally, so a bad change flips the whole chain at once.The bullet promising the opposite sat directly above the paragraph describing the automation that broke it.
This was demonstrated live while writing this: merging Renovate #1 cut
1.0.2and movedv1with no human step in between.What changes
Only the documents. The automatic move is deliberate and stays.
mainis a rollout. Verify in the pull request, because after the merge it is live everywhere.git tag -f v1 <previous tag> && git push -f origin v1, not a revert. Callers hold no version of their own.@mainis still the wrong pin, but for a narrower reason than before:@v1moves only when a release is cut, so adocs:orci:commit never reaches a caller, and@v1is a version you can name in a rollback.Does this work at v2 and v3
Yes, unchanged. The
successCmdderives the major from the version rather than assuming a single digit. Verified against the real lodash template semantic-release uses:10.0.0is the one that matters: a naive first-character approach would producev1and silently clobber the tag repos are still pinned to.Releasing
2.0.0createsv2and stops touchingv1, which freezes at the last1.x. That is what a caller pinning a major is paying for.One caveat is now recorded.
mainis the only release branch, so once2.0.0ships there is no way to release a1.xpatch. That needs"branches": ["main", "1.x"]in.releaserc.json, and it is easier to add before an incident than during one.Verification
Docs only, no behaviour change. Suite green: agent-gate 28/28, sticky-comment 10/10, preset table agrees, release and Renovate config parse, all YAML parses.